> How does one code a suid program so that it evades these problems with > symlink race conditions? Is there a way to atomically check if a file > is a symlink and open it, or is there another stratedgy? I was investigating this a while ago (because I thought I found a potential race in the 4.4BSD mail.local.c; it may still be there except that to exploit it you need write perms in /var/mail) After checking the man pages in Solaris 2.x and NetBSD, and confirming it in NetBSD by checking the kernel sources, I discovered an interesting fact: when using open(), with flags of O_EXCL and O_CREAT, the following condition holds true: If O_EXCL is set and the last component of the pathname is a symbolic link, open() will fail even if the symbolic link points to a non-existant name. So this can be used to ensure that people can't exploit the race condition where you symlink to a non-existant file and get it created for you, since open() is effectively testing this atomically for you. Unfortunately, it appears that older systems (possibly including SunOS 4 and Ultrix) don't have this check. In many cases, the race condition is in creating a new file as a priviliged user in a directory where unpriviliged users can create files/symlinks (e.g, 1777 /var/spool/mail.) If the directory has such permissions, shouldn't the appropriate method be to seteuid(target_user) before creating the file? If restricted directories (755 /var/mail) are used, the race condition can't be exploited, but root perms should only be used for the initial file creation; once the file is there and owned by the user, switching to their uid to complete the work should be safe, correct? -- Luke Mewburn <lm@werj.com.au> ``Think of it as Evolution in Action'' -- 'Oath of Fealty', Niven & Pournelle